A pthread_mutex_t can be statically initialized without any function calls. A lock takes 2 atomic operations so adding more overhead is significant. Why not just statically initialize them?

You are correct. This is not a perf-sensitive piece of code, if you're invoking a Once in a tight loop you should probably figure out how to refactor it outside of that tight loop. Other than that we do not have statically initialized mutexes right now (in the same sense of statically initialized pthread mutexes), and we would have to find a solution for windows before guaranteeing that a mutex is no allocations.

Regardless, a Once primitive is useful to have as an encapsulation that logic should run once and only once.

This might be better called Lazy<T> since it's doing lazy initialization. Once has other connotations in Rust.

Maybe lazy.get() instead of doit

Oh, I didn't realize this was mutex-specific.

I should have read the code before commenting. Now I understand what this is about.

I'm not sure that this is appropriate in init since it implies that init may be called more than once, while cleanup has no such promise. Having multiple threads calling init/destroy pairs seems like a recipe for disaster. What's the intent here?

@alexcrichton: It seems to me that Rust should stop being overly opinionated and let you initialize statics as you can in C++. It's a significant performance hit to need branches like this in every function using some globally initialized state. The work has to happen at some point, so why not run it before main and avoid branching everywhere?

Let's discuss life before main in a different issue, that is not the topic of this pull request.

@brson, no particular reason to use a Once in runtime initialization, it probably shouldn't (as you've noted) as it's not intended to be called concurrently.

Updated to remove the usage of Once during init, it's just totally unsynchronized now (because it expects one and only one caller)